CSE403 Software Engineering, Autumn 1999

David Notkin

Lecture #6 Notes

Project Management

1) Today’s educational objective

a) Understand that there are different approaches to project management for software

b) And what several of those are

c) Acquire some specific improvements about how to manage your class group and project

2) Project management

a) As I'm sure you've heard, a lot of time in a software project is spent doing other things than writing code

b) My guess is that you’re already sensing that producing the documents is easier than the issues of managing your group and your project

3) Problems include

a) Figuring out and coordinating schedules

b) Handling communication among the team

i) The figures below show a rough notion of the cost of team communication

ii) The theory is that about 25% of each group's effort is spent in communication, with this cost applying recursively

iii) As Brooks observes, the worst case of this is adding people to a late project, which tends to make it even later

c)

Making decisions

d) Recording decisions

e) What else?

4) Team structure

a) Brooks talks about the desire everyone has for a small, sharp team

b) 10 or fewer people

c) All of them brilliant

d) All of them focused on the task at hand

e) But he observes that this is too slow a way to build a really big system

5) Why? Time

a) Brooks: take a 10 person team composed of people all 7x better than the worst

b) 5x to 25x are within known ranges

c) Assume OS/360 was built by the worst

d) Assume a small team has a 7x communication benefit

e) Assume no turnover of the team

f) Assume 5000 person-years for OS/360

g) Þ 10 actual years for the task

h) Now, do the same estimates for NT 5.0 with 60,000,000 lines of code!

6) Chief Programmer Team

a) An alternative idea is to restructure a classic big team to get the benefits of the small, sharp team (ability and focus) with the benefits of a bigger team (overall speed)

b) The key is to design the positions on the team very carefully

7)

1999

a) Most of these specific (lower-level) job descriptions are clearly out of date

b) “…a team will rarely need its own machine and operating system crew”

c) “All computer input goes to the clerk, who logs and keys it”

d) But the idea of focusing on how to break up the team into well-defined jobs is, of course, still extremely pertinent

8) Chief Programmer Team

a) An underlying theme of this approach is that a smart person understands the domain and defines an appropriate architecture

b) Then the subpieces are spawned off to people who are talented programmers but who have little (or less) knowledge about the project

9) Aside: outsourcing

a) Over the past years, there has been an increased interested in outsourcing significant pieces of software projects

b) In particular, the interest has been to use cheaper labor in places like India, China, Ireland, etc.

i) There is a big political issue related to this, which is the question of granting H1-B visas to people from other countries to work in high-tech in the U.S.

c) This in many ways resembles aspects of the chief programmer team — “Give them the spec and let them code!”

d) My personal view

e) A serious problem with the outsourcing version of coding is the increased distance between the programmers and the people who own the requirements

f) Communication is almost entirely by email, travel is costly and time consuming, etc.

g) I believe this leads to less and less effective communication, significantly increasing risks

10) Some Microsoft job titles

a) Program Manager
Maintaining the big picture. Weighing risks against costs. Understanding many disciplines. Keeping a variety of specialists on the same page. Sewing all the components of a project together to make world-class software projects happen on time, on budget.

b) Software Design Engineer
Working with other product team members from the beginning of the product cycle through release, our SDEs design and implement sophisticated products ...

c) SDE in Test
Deeply involved in every phase of the product cycle, our SDEs in Test devise and implement test plans and strategies. … It's a specialized skill that requires the ability to effectively second-guess our other developers.

d) Software Test Engineer
As the strongest advocate our end-users have, Microsoft Test Engineers develop and execute test plans and scripts designed to detect problems and ensure the quality ...

11) Your team structure

a) Most likely, you’ll have a non-hierarchical team structure

b) Nobody will be the boss

c) Everyone can communicate with each other

d) But I hope not everybody sees everything

e) This does not generally scale well

f) Specific recommendation: Put someone in charge of specific decision making aspects.

g) A very common problem is to fight for a long time over decisions for which either alternative is adequate; often, making a decision is more important than which decision is chosen.

12) Artifacts

a) You may find various kinds of artifacts helpful for your project management task

b) Some, of course, may appear in your actual project, as well

c) As always, (a) use what you want and (b) don't over do anything!

13) The primary example is a Gantt chart to show the link between tasks and time

a) A Gantt Chart maps tasks to dates

b) There is a row for each task; the columns represent dates

c) This makes it easy to see the schedule

d) So it’s often a good way to build an initial plan, to view the schedule, and to make adjustments

e) Task linking is a constraint that says, “Task x cannot start until Task y completes”

14) PERT charts

a) Displays tasks and task dependencies as a network diagram or flowchart

b) A node represents each task and a line connecting two boxes represents the dependency

15) Decision making

a) Your biggest risk, in general, is not that you’ll make a bad decision

b) It is that you’ll delay making any decision past a point of no return

c) You should probably spent relatively little time deciding between two pretty strong alternatives

d) This is perhaps especially true in your project, given the incredibly compressed schedule

16) Recording decisions

a) In your meetings you will be making a lot of decisions

b) Who will do what, what will the requirements be, what system architecture will we use, who will write up what, what coding standards (if any) will we use, how will we name our variables, and many, many more

c) You cannot record all your decisions in writing…but you’d better record the key ones! (Where will you record them, and how?)

17) Running meetings

a) Have an agenda

b) Have a person responsible for keeping the meeting on the agenda

c) Have a person record key decisions

d) This person can rotate or can be assigned to someone who is good at this by nature

e) Show up to the meetings (uh, and classes)

f) Start them and end them on time

g) All common sense, all worth remembering

h) These “minor” details

i) It may be that your team’s ability to succeed is driven as much by things like how your meetings run as by how well you cut code

18) “Software engineering is not a mere matter of programming”